Embodiments of the present invention are directed to systems, apparatuses, and methods for conducting payment transactions using mobile devices, and more specifically, to an architecture or platform for a mobile payment application that may be installed in a mobile client device, such as a mobile phone, personal digital assistant, or portable computing device. Embodiments of the invention provide a set of functional modules to enable a consumer to utilize their mobile device to conduct payment transactions in a secure and efficient manner that can be implemented on a variety of platforms.
Consumer payment devices are used by millions of people worldwide to facilitate various types of commercial transactions. In a typical transaction involving the purchase of a product or service at a merchant location, the payment device is presented at a point of sale terminal (“POS terminal”) located at a merchant's place of business. The POS terminal may be a card reader or similar device that is capable of accessing data stored on the payment device, where this data may include identification or authentication data, for example. Data read from the payment device is provided to the merchant's transaction processing system and then to the acquirer, which is typically a bank or other institution that manages the merchant's account. The data provided to the acquirer may then be provided to a payment processing network that is in communication with data processors that process the transaction data to determine if the transaction should be authorized by the network, and assist in the clearance and account settlement functions for the transaction. The authorization decision and clearance and settlement portions of the transaction may also involve communication and/or data transfer between the payment processing network and the bank or institution that issued the payment device to the consumer (the issuer).
Although a consumer payment device may be a credit card or debit card, it may also take the form of a “smart” card or chip. A smart card is generally defined as a pocket-sized card (or other portable payment device) that is embedded with a microprocessor and one or more memory chips, or is embedded with one or more memory chips with non-programmable logic. The microprocessor type card typically can implement certain data processing functions, such as to add, delete, or otherwise manipulate information stored in a memory location on the card. In contrast, the memory chip type card (for example, a prepaid phone card) can typically only act as a file to hold data that is manipulated by a card reading device to perform a pre-defined operation, such as debiting a charge from a pre-established balance stored in the memory. Smart cards, unlike magnetic stripe cards (such as standard credit cards), can implement a variety of functions and contain a variety of types of information on the card. Therefore, in some applications they may not require access to remote databases for the purpose of user authentication or record keeping at the time of a transaction. A smart chip is a semiconductor device that is capable of performing most, if not all, of the functions of a smart card, but may be embedded in another device, such as a mobile phone.
Smart cards or chips come in two general varieties; the contact type and the contactless type. A contact type smart card or chip is one that includes a physical element (e.g., a magnetic stripe or other form of contact) that enables access to the data and functional capabilities of the card, typically via some form of terminal or card reader. A contactless smart card or chip is a device that incorporates a means of communicating with the card reader or point of sale terminal without the need for direct physical contact. Thus, such devices may effectively be “swiped” (i.e., waved or otherwise presented in a manner that results in enabling communication between the contactless element and a reader or terminal) by passing them close to a card reader or terminal. Contactless cards or chips typically communicate with a card reader or terminal using RF (radio-frequency) technology, wherein proximity to the reader or terminal enables data transfer between the card or chip and the reader or terminal. Contactless cards have found uses in banking and other applications, where they have the advantage of not requiring removal from a user's wallet or pocket in order to participate in a transaction. A contactless card or chip may be embedded in, or otherwise incorporated into, a mobile device such as a mobile phone or personal digital assistant (PDA). Further, because of the growing interest in such cards, standards have been developed that govern the operation and interfaces for contactless smart cards, such as the ISO 14443 standard.
A Subscriber Identity Module (SIM) is a security module that may be used for authentication operations in a mobile device (e.g., cellular telephone). SIM hardware typically consists of a microprocessor, ROM, persistent EEPROM memory, volatile RAM, and a serial I/O interface. SIM software typically consists of an operating system, file system, and application programs. The SIM may incorporate the use of a SIM Toolkit (STK), which is an application programming interface (API) for securely loading applications (e.g., applets) or data to the SIM for storage in the SIM and execution by the mobile device. The STK allows a mobile operator (such as a wireless carrier) to create/provision services by loading them into the SIM without changing other elements of the mobile device. One convenient way for loading applications to the SIM is over-the-air (OTA) via the Short Message Service (SMS) protocol.
Secure data or application storage in a smart card or other device may be provided by a Secure Element (SE). The SE can be embedded in the logic circuitry of a mobile device, can be installed in a SIM, or can be incorporated in a removable SD card (secure digital memory card), among other possible implementations. Depending on the type of Secure Element (SE) that hosts an applet, the features implemented by the applet may differ. Although an SE is typically Java Card compliant regardless of its form factor and usage, it may implement features or functions (included in the operating system and/or in libraries) that are specific to that type of SE. For example, a UICC (Universal Integrated Circuit Card) may implement features that are used for network communications, such as text messaging and STK, whereas in certain embedded SE devices, these features may not be implemented.
As the methods and devices used for conducting mobile payments develop, new functions and services will be created, as well as new devices in which those functions and services are implemented. However, to most efficiently enable the development and deployment of such mobile payment functions and services, it is desirable to have a system architecture that can be implemented in a variety of platforms (such as mobile phones that incorporate SIM cards, mobile phones that incorporate secure elements, smart phones, PDAs, etc.). It is also desirable to have a system architecture that interacts with a payment application in a manner that enables updates to the payment application to be performed without compromising the operation of the functional modules used to implement the mobile payment processing functions for the mobile device. It is also desirable to have a system architecture for use in implementing mobile payment methods that provides sufficient security for a consumer's payment account and transaction data, even in the situation where the payment application is updated.
Java Card programs typically use a data format known as an “export file” to provide information about and access to application programming interfaces that are utilized by a routine that is part of an application designed to execute on a platform such as a Secure Element (SE). If the interfaces do not exist on the platform, or if the export file data is not available, then it is not possible to load a Java Card program (i.e., an “applet”) onto that platform. For this reason some platforms may be limited in terms of the types of applications or functions that they can support.
What is desired is an architecture or system design for conducting payment transactions on a variety of mobile device platforms that provides sufficient security for a consumer's payment account and payment transaction data, and which interacts with a payment application in a manner that allows for updating the payment application without compromising the operation of other functions of the mobile payment device. Embodiments of the invention address these problems and other problems individually and collectively.